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Remarks 

Claims 1-13 are pending in the present application. All pending claims have been 
rejected under 35 U.S.C. §103 as obvious based on U.S. Patent No. 6,892,163 to Herzog et al., in 
view of U.S. Published Application No. US 2003/0093521 Al to Schlonski et al. Applicants have 
amended certain of the claims, and provide argument below as to the patentability of the claims 
as now amended over the prior art of record. 

Herzog et al. relates to equipment health monitoring involving the use of a parameter 
estimation modeling technique called "MSET", which is a form of kernel-based modeling 
described for use in the present invention. According to Herzog et al, the MSET technique 
provides estimates which are differenced with actual measured sensor signals to provide 
residuals (as in the present invention) which are analyzed to provide early detection of faults 
(such as in the present invention). The focus of Herzog et al. is to provide an improved 
statistical test for the residuals. The prior art test is a sequential probability test, which assumes 
a distribution of residuals that is Gaussian. Herzog et al. provide a method for determining a 
non-Gaussian distribution for use in the test. These modified statistical tests then are the "fault 
detection models" (see, e.g., col. 11, line 41) described by Herzog et al. for an asset, and there is 
one for each sensor, since each sensor can provide a residual signal to be tested with a specific 
modified distribution. These are not to be mistaken with the multiple models required under 
the present invention to model a fleet of assets. The issues of monitoring fleets of assets are not 
considered by Herzog et al. The disclosure of Herzog et al. with respect to modeling with 
MSET and producing residuals for an asset is entirely conventional, and discloses only 
monitoring an asset. For example, at col. 5., lines 10-15 (called out in the Examiner's office 
action), "assets" is used in the plural, but is not meant in the sense of a fleet of many assets, but 
rather in the sense that many different kinds of assets could be (individually) the subject of the 
monitoring described by Herzog et al. Herzog et al., do not provide any teaching with respect 
to a software system having multiple models for monitoring fleets of assets, including fleets that 
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may be best viewed in a hierarchical fashion. As a consequence, Herzog et al., do not deal with 
the special issues raised in monitoring so many assets with such large data streams in an 
efficient manner. 

Schlonski et al., articulate what amounts to a database for information relating to assets, 
mainly assets that can be communicated with over a network, such as copiers and printers in an 
office. The Schlonski et al. system has the capability to store asset information in a hierarchical 
fashion, but does not present a comprehensive view of the status of all such assets at a node of 
the hierarchy, as is provided in the present invention. The hierarchical view of Schlonski et al. 
is merely a navigation tree. The information stored in the system is broadly related to 
management of the assets, including information about who the point-of-contact is, how long 
the asset is under warranty, the measure of use of an asset (e.g., pages copied on a copier), the 
make and model of the asset, the capabilities of the asset, and so on. As such, the system of 
Schlonski is not meant to be an interactive real-time equipment health monitoring system, but 
rather is more in the nature of an inventory system with some work order management. 

Sensor data is not provided to the system of Schlonski et al.; instead, network- 
communicable assets are periodically queried and report their status: Usage information, 
operating status, or error messages determined by processors onboard the asset. Error messages 
contemplated by Schlonski et al. are messages determined at the asset, not by the system of 
Schlonski et al. As is commonly known in the art from the use of printers and copiers (which 
are the focus of Schlonski et al), such assets report errors as conclusive diagnostic "codes", 
rather than directly reporting the sensor data from whatever sensors are contained in the asset 
itself. To the extent the system of Schlonski et al. is designed to store information about 
equipment failures as the "fault history of a particular asset" (paragraph 32, called out by the 
Examiner), this is a retrospective report, not a prospective report, and is not the same as the 
watchlist described in the present application to list the current and incipient faults across a 
fleet of assets. A fault history report for a particular asset would do little to enable forward- 
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looking maintenance actions, such as are enabled by the modeling and exception-based 
reporting of the present invention. 

In FIG. 8, Schlonski et al. further show an administrative screen shot that indicates error 
messages received from assets can be prioritized in terms of how they are handled. Higher 
priority error messages may be elevated to pop up a message on a user's screen, while lower 
priority error messages may be reported collectively on an hourly or daily email report 
(paragraph 35). The error messages exemplified in FIG. 8 of Schlonski et al. show that these are 
errors reported by the devices. For example, at paragraph 37, Schlonski et al. discuss the 
problem that different assets from different vendors use different and arbitrary fault codes. It is 
clear that the faults are thus determined entirely at the asset level by computations performed 
in the asset, and then provided only as a code to the system of Schlonski et al. There is no ability 
to drill down into these messages to examine why they are occurring, in contrast to the present 
invention, because all that Schlonski et al. store are the messages, not any sensor data, modeling 
estimates, residuals or time series of any sort. 

The present invention provides an effective means for efficiently dealing with alerts and 
faults across a large fleet of assets, by providing a watchlist of those assets with current 
problems revealed by the modeling engine of the invention. Further, the watchlist provides for 
drill-down into the incidents that put the asset on the watchlist, the sensors that are involved in 
the incident, and the time series charts showing the sensor data and model estimates, and 
corresponding residuals. In the context of sensitive early fault detection as enabled by the 
modeling approach of the current invention, this provides an efficient interface for a user to 
investigate only those assets that have current problems, and to rapidly examine the source 
incidents and supporting data that put the asset on the watchlist. This is extremely useful in an 
advanced warning system, to enable investigation of early warning signs efficiently, where such 
signs may only be occurring on a small fraction of total assets monitored. Neither Herzog et al. 
nor Schlonski et al., alone or in combination, provides or teaches this. Applicants respectfully 
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assert the claims of the present application are not obvious in view of these combined 
references. 

Claim 1 provides for a sensor data fed from a fleet of assets, a database containing 
models for each of the assets, an estimation engine, and an incident diagnostics engine, coupled 
to provide a graphical interface module, or a GUI output, that provides a view specific to those 
assets having a registered incident, i.e., a watchlist. Claim 1 has now been amended to remove 
the limitation relating to hierarchical presentation, which has been shifted to new dependent 
claim 18. Claim 1 has further been amended to include the capability of the watchlist to provide 
direct access to the supporting information as to why an asset is on the list, namely the 
incident(s) that were triggered in order to put the asset on the list. The watchlist and its drill- 
down feature are not contemplated by either Herzog et al., or Schlonski et al. In Herzog, fleet 
asset monitoring is not addressed at all. The teachings of Schlonski et al. do not describe a 
watchlist with drill-down into the list of incidents that were triggered to put the asset on the 
watchlist, because Schlonski is merely storing error messages determined at the asset level, not 
within the system of Schlonski et al. itself. 

Therefore, it would not be obvious to one skilled in the art to expand the model-based 
monitoring described by Herzog et al. to a fleet system and extract from the teachings of 
Schlonski et al. that a watchlist of assets with problems having the capability for rapid and 
relevant drill-down should be added to such a system; claim 1 as now amended would not be 
obvious from a combination of these references. 

Claims 2-8 depend from claim 1, and therefore would also not be obvious. 

Claims 9-12 have been cancelled in favor of new claims in which their features have 
been claimed. 

Claim 13 has been amended to depend from claim 1 instead of now-cancelled claim 12. 
New claims 14-19 have been added. 

Claim 14 extends claim 1 in that the drill-down into the supporting information includes 
display of sensor data, estimates and residuals for the asset. Hence, from the exception-based 



Page 9 of 11 



Application No. 10/802,251 
Amendment "A" dated February 12, 2007 
Reply to Office Action of September 11, 2006 

view, a user can select an asset and immediately and efficiently investigate the supporting data 
streams. Neither Herzog et al. nor by Schlonski et al. provides this, and is non-obvious over the 
combination of these references. 

Claim 15 extends claim 14 in that once the incident(s) are displayed for an asset on the 
watchlist, an incident can be selected to enable display of a predetermined set of charts of data 
relating to that incident. As a hypothetical example, a particular incident may be understood as 
supported by a high temperature on Sensor A, a low pressure on Sensor B, and no deviations 
from expected behavior, i.e., no residual on Sensor C; then those charts may be preconfigured to 
display when the incident is selected from the watchlist to instantly show these parameters to 
the user so the user can confirm them or investigate the degree to which they are true. This is 
entirely absent from any of the prior art of record. 

New claim 16 depends from claim 1, and describes that after an asset has been selected 
on the watchlist such that its incident(s) are displayed, then an incident may be selected to 
obtain a list of the sensors involved in the incident, that is, that were used to determine the 
incident had been triggered. Any such listing of sensors "responsible" for the incident is absent 
from Herzog et al. and from Schlonski et al. 

Claim 17 extends claim 16 by making the sensors listed selectable to then present one or 
more of the raw sensor data, estimates or residuals for that sensor. In this manner, the user can 
drill-down efficiently to the sensors involved in triggering the incident right from the watchlist 
and display the data from the sensor for further investigation. This is absent from the prior art 
of record. 

Claim 18 depends from claim 1 and introduces the hierarchical feature that was 
removed from claim 1. Accordingly, a hierarchical presentation of the assets in the fleet being 
monitored is provided by the graphical interface module, and upon selecting a node from that 
hierarchy, the watchlist is limited to assets under that node that exhibit current incidents. In 
this way, the user can hone in on a particular subfleet of assets to see which of those require 
investigation. This can be extremely useful where the software system of the present invention 
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is used by more than one user, each responsible for maintenance and trouble tracking in only a 
subset of the assets being monitored. This is entirely absent from the prior art of record, and is 
therefore non-obvious. 

Claim 19 expands on claim 18, to indicate that the hierarchy includes nodes at a level of 
collections of assets; at a level of the asset; and at a level of various modes of operation of the 
asset. This is not present in the prior art of record. 

Conclusion 

Applicants have amended certain of the claims, and provide argument as to the 
patentability of the claims as now amended over the prior art of record. Neither Herzog et al. 
nor Schlonski et al. contemplate the special needs of monitoring large numbers of assets with an 
advanced warning system using an estimation engine, and therefore do not in combination 
make the claims as amended obvious. Applicants respectfully urge allowance of the claims by 
the Examiner over the art of record. 
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